Overall productivity and speed/#8153

Sep 2, 2009 / clawfrown
Apr 22, 2012 / pixtur
 

Attached files

No files uploaded
 
Streber looks very promising in terms of logic/structure/potential.
Though I have some concerns about speed of working and reliability.

Please tell me that this more than 30000ms for rendering list of tasks is just because of a poor server?
  1. Or please advice how it could be speeded up? Is that a server or internet issue or that is impossible because of PHP restrictions (comparing to Ruby)?
  1. Reliability. Is it stable as a stone or there are some weak points exist?

5 Comments

luchyx:

5 years ago

I know that the project was developed by pixtur in his spare time and for learning php purpose.
I saw the same issues that you wrote above.
After read and modify few lines of code I noticed that:
  • the whole task and project "model" is fully loaded on php.
  • many operations, like sumarization are computed by PHP.
  • no views stored on DataBase.Implementing this will reduce Memory Usage.
  • Each Task Instance is fully loaded no matter the context.
I like streber. I wish have more time to spend on streber!

clawfrown:Thank you luchyx for some explanation

5 years ago (2. update 5 years ago)

Though when you say "fully loaded on php" does that mean it is server CPU that is the bottleneck?

Just thought that adding some "pages" to tasklist might solve the problem somehow.

luchyx:

5 years ago (2. update 5 years ago)

I'm trying to say that the collection of tasks (DTO data transfer objects) is not optimized having in mind the context.

For example. It's load the description field no matter if you are on the "task list" or in the "overall changes" context.

"pixtur could be more precise here."

clawfrown:

5 years ago

Thank you for explanation, I seem to understood that.
But just wonder if using the brute force by setting up very strong server could have been make it faster?

pixtur:

25 months ago

Good discussion. Database performance is actually not the biggest issue. Memory consumption is harder to fix. We have an installation with 20000 items over 20 or so projects with around 100 users. It's running okayish on a virtual ubuntu server.