simultaneous accesses are slow!

[cyberic99]

I'll try to explain. Maybe this is due to the configuration on my server.

To reproduce the problem, you must have a lots of feeds (like me ;-))

When I click 'update all', I see the updates.

If I open one of the feeds in another browser tab, while update is still running, the tab seems blocked for a long time.

Is it normal?

Are there locks somewhere in the code?

[tontof]

I guess this is because the server does not allow concurrent access. If you want to update when reading, it's better to use javascript update where feeds are update one by one.

[cyberic99]

Is it a limitation of php? of apache? I have several apache processes spawned...

In fact, event in 'javascript update mode', things seem slower...

This is why I wanted to know if something else could block a second instance: cookies, sessions, file locking etc

[tontof]

Indeed, javascript update is slower but it lets to read items immediately. I guess the limitation is because of apache configuration, but I don't know exactly.

[cyberic99]

It seems strange to me that apache could be blocking simultaneous access to a file, it is the purpose a a server after all... Do you want my opml subscription list with a large number of feeds?

[cyberic99]

Just to let you know, I disabled session protection, just to try, and it didn't solve the problem

[tontof]

Actually I have exactly the same problem with my feeds (on my own and on my hosted server). But for me it's not really a problem with KrISS feed. I did not look to fix that as for me it was link to server configuration.

[cyberic99]

In fact, here, they say that if the two requests come from the same browser, the second one can be delayed: http://stackoverflow.com/questions/1430883/simultaneous-requests-to-php-script

I don't know haw the problem can be solved easily...

[tontof]

I guess you find the problem and the solution :

there is some lock somewhere -- which can happen, for instance, if the two requests come from the same client, 
and you are using file-based sessions in PHP : while a script is being executed, the session is "locked", which 
means the server/client will have to wait until the first request is finished (and the file unlocked) to be able to use 
the file to open the session for the second user.

For me, there is no solution :-(

[cyberic99]

In fact, it depends.... It depends on when you need to write sessions variables... You should call session_write_close(); as soon as possible. After than, you can still read from the session , but no more write to it. Is it possible ?

Or you could use alternative ways to store sessions variables, such as "cachecookie" here: http://00f.net/2011/01/19/thoughts-on-php-sessions/

By the way, could you compile a quick and dirty "developer guide", that would enable more people to get into the code? The code seems very readable, but a few hints and explanations of the code structure, of the data files and so on could be helpful. Thanks.

[tontof]

I will try to think about session_write_close(); because I don't use session that much.

developer guide... definitely ! 24 hours a day is too short :-( I will do it right after version 7 !

[GuillaumeMichon]

I experience the same problem. My hoster (PlanetHoster) limits to 3 simultaneous processes, which makes AJAX orders fail frequently.

What you can do: 1) Use best practices for sessions: session data should be accessed and writed as early as possible, then session_write_close().

2) Implement a request queue in your javascript and a simultaneous process limit (tunable in options).

[cyberic99]

Or you can an alternative session manager with less strict locking...

[tontof]

Actually as I did not think about that at the beginning, I need to modify things when updating a new feed because I modify the session at the end of each update : https://github.com/tontof/kriss_feed/blob/master/index.php#L6627

However that's strange that AJAX fails frequently because I do not have that kind of problems and it should just take more time, not failing...

I will try to remove the session part on update to be able to call session_write_close as soon as possible

[cyberic99]

I think that the browser is already throttling ajax requests, isn't it?

[tontof]

Well I don't know, but I can perform a lot of simultaneous AJAX queries with no problem when updating. It takes more time, but it works on my browser with no problem.

[GuillaumeMichon]

I think it depends on server settings. My hoster kills requests beyond 3 with error 500. Hosters have unlimited imagination to limit hosting... I plan to change. But now, you know it exists.

[tontof]

Thanks for the feedback. I hope I will be able to remove this constrain to unlock session during update.